home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-moore-smtp-drpt-00.txt
< prev
next >
Wrap
Text File
|
1993-09-17
|
22KB
|
548 lines
Network Working Group Keith Moore
Internet Draft University of Tennessee
16 September 1993
SMTP Service Extension
for Delivery Reports
draft-moore-smtp-drpt-00.txt
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. (The
file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil,
describes the current status of each Internet Draft.) It is not
appropriate to use Internet Drafts as reference material or to cite them
other than as a "work in progress".
2. Abstract
This memo defines an extension to the SMTP service whereby the an
SMTP client may specify to an SMTP server the conditions under which a
delivery report should be generated.
3. Introduction
The SMTP protocol [1] requires that an SMTP server provide
notification of delivery failure, if it determines that a message cannot
be delivered to one or more recipients. Traditionally, such
notification consists of an ordinary Internet mail message (format
defined by [2]), sent to the envelope sender address (the argument of
the SMTP MAIL command), containing an explanation of the error and at
least the headers the failed message.
Experiences with large mail distribution lists [3] indicates that
such messages are often insufficient to diagnose problems, or even to
determine at which host or for which recipients a problem occurred. In
addition, the lack of a standardized format for delivery notifications
in Internet mail makes it difficult to exchange such notifications with
other message handling systems.
This memo uses the mechanism defined in [4] to define an extension to
the SMTP service, by which an SMTP client may request that an SMTP
server issue or not issue a delivery status notification (DSN) under
certain conditions. The format of a DSN is defined in [5].
K. Moore Expires 16 March 1994 [Page 1]
Delivery Reports 16 September 1993
4. Framework for the Delivery Report Extension
The following service extension is therefore defined:
(1) The name of the SMTP service extension is "Delivery Report";
(2) the EHLO keyword value associated with this extension is "DRPT", the
meaning of which is defined in section 5 of this memo;
(3) no parameters are allowed with this EHLO keyword value;
(4) three optional parameters are added to the RCPT command, and one
optional parameter is added to the MAIL command:
An optional parameter for the RCPT command, using the esmtp-keyword
"DRPT", (to request a delivery-report), is defined in section 6.1,
An optional parameter for the RCPT command, using the esmtp-keyword
"NORET", (to specify that delivery reports not return the contents
of a message), is defined in section 6.2,
An optional parameter for the RCPT command, using the keyword "TAG",
(used to communicate additional information for use by internetwork
mail gateways), is defined in section 6.3, and
An optional parameter for the MAIL command, using the keyword
"MSGID", (used to propagate a unique identifier to be returned in a
delivery report), is defined in section 6.4;
(5) no additional SMTP verbs are defined by this extension.
The remainder of this memo specifies how support for the extension
affects the behavior of a client and server SMTP.
5. The Delivery Report service extension
An SMTP client wishing to request a delivery report for a message may
issue the EHLO command to start an SMTP session, to determine if the
server supports any of several service extensions. If the server
responds with code 250 to the EHLO command, and the response includes
the EHLO keyword DRPT, then the Delivery Report extension is supported.
When any SMTP server returns a positive (2xx) reply code in response
to a RCPT command, agrees to accept responsibility for either delivering
the message to the named recipient, or sending a notification to the
sender of the message indicating that delivery has failed. By returning
a DRPT keyword in response to an EHLO command, a server also agrees to
generate a Delivery Status Notification (DSN) according to the
parameters of each RCPT command, when it returns a positive response to
the RCPT command. (The client SMTP is responsible for generating the
K. Moore Expires 16 March 1994 [Page 2]
Delivery Reports 16 September 1993
necessary delivery reports if the server SMTP returns a failure reply
code.) Such DSNs must be in the format defined in [5].
The additional parameters allow the sender (via the client SMTP) to
specify that a delivery report should be issued:
(a) upon successful delivery or failure to deliver a message, or
(b) only on failure to deliver a message, or
(c) not at all.
In addition, the sender may specify that the contents of a message
are not to be returned in a delivery report.
6. Additional parameters for RCPT and MAIL commands
The extended RCPT and MAIL commands are issued by a client with it
wishes to request a delivery report from the server, under certain
conditions, for a particular recipient. The extended RCPT and MAIL
commands are identical to the RCPT and FROM commands defined in [1],
except that one or more of the following parameters appear after the
sender or recipient address, respectively. The general syntax for
extended SMTP commands is defined in [4].
6.1 The DRPT parameter of the ESMTP RCPT command
The esmtp-keyword "DRPT" may be appear in the RCPT command to modify
the default behavior of the MTA when generating delivery notifications
for that recipient. Acceptable esmtp-values for the DRPT parameter are
the following:
ALWAYS always generate a delivery report on delivery
FAILURE generate a delivery report on delivery failure only
NEVER do not generate a delivery report
If no DRPT parameter appears, the server should generate a delivery
report only upon failure to deliver a message. This is the behavior
specified by [1]. Ideally, servers should use the delivery report
format defined in [5] to report delivery failures, even if they do not
implement this SMTP extension.
A DRPT esmtp-keyword with an esmtp-value of ALWAYS indicates that the
server should accept responsibility for generating a DSN (in the correct
format) upon any of the following conditions: (a) successful delivery to
the indicated recipient's mailbox, (b) relaying or gatewaying of the
message into a environment that cannot or will not accept responsibility
for generating well-formatted DSNs, (c) forwarding of the message to a
mailbox other than that specified by the sender, or (d) failure to
deliver a message.
K. Moore Expires 16 March 1994 [Page 3]
Delivery Reports 16 September 1993
A DRPT esmtp-keyword with an esmtp-value of FAILURE indicates that
the server should accept responsibility for generating a DSN when (a)
relaying or gatewaying of the message into an environment that cannot or
will not accept responsibility for generating well-formatted DSNs, or
(b) forwarding of the message to a mailbox other than that specified by
the sender, or (c) failure to deliver the message.
A DRPT esmtp-keyword with an esmtp-value of NEVER indicates that the
server should not generate a DSN under any conditions, and should accept
responsibility for ensuring that no DSN is generated for this recipient.
(If the message is further relayed via a SMTP server that does not
support this extension, this may be accomplished by using an empty
sender address in the MAIL command. This may require a separate SMTP
session if not all recipients have DRPT=NEVER.)
6.2 The NORET parameter of the ESMTP RCPT command
The presense of the NORET esmtp-keyword on the extended RCPT command
indicates that the message should not be included in any delivery
notification issued for this recipient. A missing NORET parameter
indicates that a message should be returned in a delivery notification
for this recipient.
6.3 The TAG parameter to the ESMTP RCPT command
A TAG esmtp-keyword is used to convey additional per-recipient
information for messages which originated in an non-SMTP environment,
and for which a delivery report was requested by the sender. The
definition of the esmtp-value is not defined by this memo; the
definition to be provided by the specifications for gatewaying delivery
reports to and from non-SMTP environments.
6.4 The MGSID parameter to the ESMTP MAIL command
The optional MSGID esmtp-keyword may appear in the MAIL SMTP command.
The esmtp-value associated with this string is formatted according to
the rules for "msg-id" in [2]. Note that this value is not necessarily
the same as in the Message-ID header field of the message.
6.5 Server responses to these commands
The presence of any of the DRPT, NORET, or TAG esmtp-keywords in a
RCPT command, or the MSGID esmtp-keyword in a MAIL command, does not
affect the server's response to that command (unless there is a syntax
error in the command itself). By issuing the DRPT keyword in response
to the EHLO command, the server has indicated its willingness to accept
these keywords and to process them according to the rules below. A
K. Moore Expires 16 March 1994 [Page 4]
Delivery Reports 16 September 1993
server MAY NOT refuse the responsibility to issue delivery reports on a
per-recipient basis.
7. Format of delivery notifications
The format of delivery status notifications is defined in [5].
Delivery status notifications are to be returned to the sender of the
original message according as outlined below.
7.1 SMTP Envelope to be used with delivery status notifications
The sender address (in the SMTP MAIL command) must be an empty
string. The recipient address (in the RCPT command) is copied from the
MAIL command of the message for which a delivery notification is being
issued. The envelope of a delivery notification may not use the DRPT
option.
7.2 Message/delivery-report Content-Type Header Parameters
The parameters of the message/delivery-report content type are
derived as follows:
The "id" parameter of the delivery-report contains the envelope
message-id as provided with the MSGID esmtp-keyword of the MAIL command
of the message for which a report is being generated.
Unless the sender requested that the message not be returned in a
delivery report, a unique content-id is generated by the reporting MTA,
and the "returned-content" parameter of the message/delivery-report
content-type header is used to indicate the content-id of that body
part.
*** NOTE IN DRAFT: It might be that delivery reports should include
the *headers* of a failed message, even if the sender requested that the
message not be returned. ***
If the text of any of the "text" body fields requires a character set
other than ASCII, the "charset" parameter should be used to indicate
that character set. Only one "alternate" character set may be used per
delivery notification. (This feature will not be used if the "text" is
copied from SMTP responses, since SMTP responses must be entirely in
ASCII.)
7.3 Message/delivery-report body field parameters
The body of the message/delivery-report body part contains a STIF [6]
record for each recipient. The fields of this per-recipient record are
K. Moore Expires 16 March 1994 [Page 5]
Delivery Reports 16 September 1993
derived as described below. These instructions apply to the generation
of delivery reports by an ESMTP client that supports this specification,
in response to SMTP or ESMTP transactions with a server. If an ESMTP
client uses some other protocol to deliver or relay a message, some of
the per-recipient fields are not required.
Refer to [5] for the syntax of each field.
orig-rcpt contains the recipient address from the RCPT command. (Since
this specification guarantees that the recipient address is
the same as specified by the sender, the "rcpt" field should
not be used.)
mta contains the Internet domain name of the SMTP that provided
the information from which this report is derived. This will
normally be the same as provided in the server's initial
greeting and the first line of the response to the EHLO
command.
date contains the date at which the last delivery attempt occurred.
action describes the action taken by the SMTP client generating the
report, as defined in section 8.
status If available, the reply-code returned by the "remote" SMTP
server that informed "this" SMTP client (the one issuing the
report) of the condition that caused the client to generate
the report for this recipient. (This field is not required if
the MTA generating the report used some protocol other than
SMTP to deliver or relay the message.)
text Either the text supplied by the "remote" SMTP along with the
reply-code in "status", or any appropriate explanatory text.
tag The esmtp-value supplied with the TAG esmtp-keyword of the
RCPT command for this recipient, if present.
7.4 Returned message body part
Unless the sender of the original message requested that the original
message not be included in a delivery report, the third body part of a
message/delivery-status-notification content should be the returned
message, or some portion (e.g. the headers) thereof.
The content-id of the returned message body part should be identical
to that provided in the returned-content parameter of the
message/delivery-report body part for this delivery notification.
8. Conformance requirements
K. Moore Expires 16 March 1994 [Page 6]
Delivery Reports 16 September 1993
An SMTP server which claims compliance with this specification MUST
implement the EHLO command as described in [4], and return the DRPT
keyword in response to the EHLO command. In addition, it MUST accept
the DRPT, NORET, and TAG parameters of the RCPT command and the MSGID
parameter of the MAIL command.
When an SMTP server accepts responsibility for delivery of a message
to a recipient whose RCPT command contains a DRPT or NORET keyword (by
returning a 2xx reply code in response to that command), it also agrees,
for each recipient, to either:
(a) transfer responsibility for the generation of a delivery
notification for that recipient, to another ESMTP server that
implements this extension, or
(b) transfer responsibility for the generation of such a notification to
a gateway into a "foreign" (non-SMTP-based) electronic mail
environment, which provides a similar delivery notification
facility, arranges for such notifications to be returned to the
sender of the message, via a gateway that will translate the foreign
delivery notifications into the format defined in [5].
(c) successfuly deliver the message to the mailbox named by the original
sender of the message, or
(d) generate a delivery status notification in accordance with this
specification.
8.1 Transfer of delivery-report information via SMTP
If an SMTP client relays a message to an SMTP server which advertises
the DRPT keyword in response to the client's EHLO command, the client
must issue a MSGID parameter to the MAIL command (if a MSGID parameter
was supplied by client's predecessor), and likewise copy the DRPT, RET,
and TAG esmtp-keywords and values along with each RCPT command relayed
to the server.
The server accepts responsibility for generating any requested
delivery reports for each recipient for which it returns a positive
(2xx) reply code in response to the RCPT command. For any failed
recipients, the client must generate a delivery report with an "action"
value of "failed", and an "mta" value equal to Internet domain name of
the server SMTP.
If an SMTP client relays a message to an SMTP server which does not
advertise the DRPT keyword in response to the EHLO command, the client
must generate a delivery report for each recipient for whom a delivery
report is required. For any failed recipients, the client will generate
a delivery report with an "action" value of "failed". For any other
recipients, the client will generate a delivery report with an "action"
value of "relayed". In either case, the "mta" value is set to the
Internet domain name of the server SMTP. If DRPT=NEVER for any
recipients, the client SMTP should relay the message to those
K. Moore Expires 16 March 1994 [Page 7]
Delivery Reports 16 September 1993
recipients, (using a separate SMTP session if necessary), with an empty
sender address in the MAIL command.
8.2 Gatewaying into a foreign environment
If an SMTP server gateways the message into a foreign electronic mail
system which supports similar delivery notifications, and can arrange
for all notifications issued from within that mail system to be returned
via a suitable gateway such that the foreign delivery notifications will
be translated into the format defined in [5], then it need issue
delivery reports only for those recipients for which the foreign mail
system would not agree to deliver the message.
The foreign mail system need not support exactly the same semantics
for delivery notification that are described here. In particular, the
foreign mail system may not be able to honor the sender's request that
the message be or not be returned along with a delivery report; and the
foreign mail system need not issue reports when mail is forwarded within
that environment. (In the latter case the gateway should use the "rcpt"
field when translating a delivery report from that environment, rather
than the "orig-rcpt" field.)
If appropriate delivery notifications from the foreign environment
cannot be provided, the SMTP server must issue a delivery report for
each recipient, containing an "action" value of "relayed", and an "mta"
value equal to the Internet domain of the SMTP server.
8.3 Delivery, forwarding, list expansion
Upon final delivery to the recipient's mailbox, as named by the
sender), an SMTP must issue any requested delivery reports with an
"action" value of "delivered" and an "mta" value equal to the Internet
domain of the SMTP server. (Note that this is not necessarily the same
as the domain part of the recipient address). If the delivery fails,
the "action" value should instead be "failed.
When a message is "forwarded" to another recipient address than that
specified by the sender, the SMTP which performs the forwarding must
issue a delivery report for that recipient (unless DRPT=NEVER), with an
"action" value of "forwarded" and an "mta" value equal to the Internet
domain of the server performing the forwarding.
*** NOTE IN DRAFT: we should use the TAG facility here to allow
propagation of delivery reports across mail forwarding boundaries. It
would be a shame to allow delivery reports to cross inter-MTS boundaries
and not to cross mail forwarding boundaries within RFC 822! ***
Successful delivery of a message to an address associated with a mail
distribution list cases a delivery report to be generated with an
K. Moore Expires 16 March 1994 [Page 8]
Delivery Reports 16 September 1993
"action" value of "delivered". Delivery report requests are NOT to be
propagated to the members of the distribution list.
9. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Westine, A., Postel, J. "Problems with the Maintenance of Large
Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March
1991.
[4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D. "SMTP
Service Extensions", RFC 1425, United Nations University, Innosoft
International, Inc., Dover Beach Consulting, Inc., Network
Management Associates, Inc., The Branch Office, February 1993.
[5] Moore, K. "MIME Content-Types For Delivery Status Notifications",
Internet-Draft "draft-moore-mime-delivery-00.txt", 16 September
1993.
[6] Crocker, D. "Structured Text Information Format (STIF)", Internet-
Draft "draft-crocker-stif-00.txt", June 1993.
10. Author's address
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
email: moore@cs.utk.edu
K. Moore Expires 16 March 1994 [Page 9]